Instead of forcing IPv4, I would like first to understand and have an explanation of why using IPv6 fails that particular environment.

Instead of forcing IPv4, I would like first to understand and have an explanation of why using IPv6 fails that particular environment.

Linux kernel would always prefer IPv6 over IPv4 when there is a choice. So it's expected to use IPv6 whenever possible. It should work.

I would like to understand better the situation too.

Instead of forcing IPv4, I would like first to understand and have an explanation of why using IPv6 fails that particular environment.

I updated the PR description

Moving it to draft, the new version is not working yet.

Ok, the changes are working

Ok, the changes are working

please change the title(s), we are not forcing ipv4 anymore

Instead of using external scripts, maybe we can use the same mechanism of local-exec + qemu-monitor-command (but with different call) that I made on my PR for the libvirt provider example.

See:

# Post-provisioning: Automatic SSH Port Forwarding 
 # Maps host port 2222 to guest port 22 via QEMU monitor command (HMP) 
 resource "null_resource" "auto_ssh_port" { 
   # Ensure the VM is created before attempting port mapping 
   depends_on = [libvirt_domain.ubuntu_vm] 
  
   # Force execution on every 'apply' to maintain the mapping 
   triggers = { 
     always_run = timestamp() 
   } 
  
   provisioner "local-exec" { 
     command = <<-EOT 
       echo "Waiting for VM to initialize..." 
       sleep 10 
       virsh -c qemu:///session qemu-monitor-command ubuntu-vm --hmp "hostfwd_add hostnet0 tcp::2222-:22" 
       echo "SSH access available at: ssh ubuntu@localhost -p 2222" 
     EOT 
   } 
 }

Instead of using external scripts, maybe we can use the same mechanism of local-exec + qemu-monitor-command (but with different call) that I made on my PR for the libvirt provider example.

See:

# Post-provisioning: Automatic SSH Port Forwarding 
 # Maps host port 2222 to guest port 22 via QEMU monitor command (HMP) 
 resource "null_resource" "auto_ssh_port" { 
   # Ensure the VM is created before attempting port mapping 
   depends_on = [libvirt_domain.ubuntu_vm] 
  
   # Force execution on every 'apply' to maintain the mapping 
   triggers = { 
     always_run = timestamp() 
   } 
  
   provisioner "local-exec" { 
     command = <<-EOT 
       echo "Waiting for VM to initialize..." 
       sleep 10 
       virsh -c qemu:///session qemu-monitor-command ubuntu-vm --hmp "hostfwd_add hostnet0 tcp::2222-:22" 
       echo "SSH access available at: ssh ubuntu@localhost -p 2222" 
     EOT 
   } 
 }

Thanks for the reference @srbarrios!

I looked at your example in dmacvicar/terraform-provider-libvirt#1288. The qemu-monitor-command approach works well for simple port forwarding, but I think the use cases are different enough to justify keeping the external scripts here. Here's my reasoning:

The core difference is that a static sleep isn't reliable enough for our CI environment, DHCP timing varies, and we need to know early if a routable IP never appears rather than getting a generic SSH timeout later.

Embedding a multi-step polling loop with grep/awk/virsh error handling inside a HCL heredoc would work, but it becomes difficult to read and debug. Keeping the logic in wait_for_ip.sh means it can be run standalone against any domain for troubleshooting.

I am not sure if this is strictly related, but I remember that when we updated the terraform-libvirt-provider we had similar issues around IPv6 and link-local addresses being used. Especially for retail.

Technically, the provider we build in OBS should be patched to avoid considering an interface ready if that's the only available address.
See https://build.opensuse.org/projects/systemsmanagement:sumaform/packages/terraform-provider-libvirt/files/ipv6.patch?expand=1

Can you double check that:

1. we are indeed using a provider binary installed from our repo and RPM. Not one pulled from the public registry.
2. if that DEBUG log pops up and there's a match with the IP causing troubles